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Kennedy Ground Control System (KGCS) engineers at the National Aeronautics and 
Space Administration (NASA) Kennedy Space Center (KSC) are developing a time-tagging 
process to enable reconstruction of the events during a launch countdown. Such a process 
can be useful in the case of anomalies or other situations where it is necessary to know the 
exact time an event occurred. It is thus critical for the timing information to be accurate. 
KGCS will synchronize all items with Coordinated Universal Time (UTC) obtained from the 
Timing and Countdown (T&CD) organization. Network Time Protocol (NTP) is the 
protocol currently in place for synchronizing UTC. However, NTP has a peak error that is 
too high for today’s standards. Precision Time Protocol (PTP) is a newer protocol with a 
much smaller peak error. The focus of this project has been to implement a PTP solution on 
the network to increase timing accuracy while introducing and configuring the 
implementation of a firewall between T&CD and the KGCS network. 
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I. Introduction 

T he Engineering Directorate at the National Aeronautics and Space Administration (NASA) Kennedy Space 
Center (KSC) is responsible for creating a new command and control system to checkout and launch future 
rockets and spacecraft. The Kennedy Ground Control System (KGCS) plays a unique role in the checkout of launch 
vehicles. KGCS duties include health management of the Programmable Logic Controllers (PLCs) on the launch 
pads, as well as the development of a process that will enable reconstruction of the events during a launch 
countdown. 

To obtain reconstruction data, KGCS will time-tag and store selected field measurement values from the 
different subsystem end-items. To ensure accuracy, KGCS will synchronize all items with Coordinated Universal 
Time (UTC) obtained from the Timing and Countdown (T&CD) organization. UTC is the time standard used across 
the world. Timing centers across the globe have agreed to keep their time scales closely synchronized to this 
standard [1]. KGCS currently synchronizes with UTC using Network Time Protocol (NTP). However, NTP has a 
peak error greater than 1 millisecond (ms), and can even reach 100 ms in a congested network. Precision Time 
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Protocol (PTP) is a newer protocol with a peak error less than a microsecond [2]. The outcome of this internship 
was the completion of a prototype network design that allows a PTP timing signal to pass unimpeded from a 
grandmaster clock to the KGCS network through a firewall. 


II. Precision Time Protocol 

Also known as the lEEE^ 1588 protocol, PTP was created by Agilent Technologies and was passed as a standard 
by the IEEE in 2002. An improved version became available in 2008, called PTPv2 or IEEE 1588-2008. This is the 
most recent version of the protocol, and has several advantages over the original, including the capability to achieve 
sub nanosecond-range accuracy, reduced network bandwidth, a revised messaging system, and faster 
synchronization [2]. 

PTP acts as a master to slave protocol. This means that in order for two PTP devices to communicate, they must 
decide which device’s clock has the higher priority - the device with the higher priority will act as the master and 
send its own time to the slave. A device that is receiving and/or transmitting a PTP signal must have its priority set 
to a number between 1 and 255. When two PTP devices connect, the device with the lower number will act as the 
master, and the device with the higher number will act as the slave. 

Once the master and slave are set, the master clock sends a sync message to the slave that is time-stamped on 
both ends to calculate the time offset [3]. Once the slave receives this message, it sends a delay request message 
back to the master clock. The master clock sends a delay response back to the slave upon receiving the delay 
request signal. The delay request and delay response signals are used in conjunction to determine the latency of the 
network between the master and slave. Once the slave knows the time offset as well as the delay, it is able to 
synchronize itself to the master clock. 


III. Early Timing Prototype 



Figure 1 - Original Timing Prototype 
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The diagram above shows the early design for the timing prototype. The timing signal would be obtained from a 
Symmetricon Grandmaster Clock^, and passed through a Juniper SRX240 Firewall to an Allen-Bradley Stratix 8000 
Boundary Clock. This boundary clock would distribute the timing signal throughout the KGCS network. 

A. Symmetricon Grandmaster Clock 

The Grandmaster Clock is simply the origin of the UTC time signal. It is controlled by T&CD and is capable of 
transmitting a timing signal via FTP as well as NTP. Where PTP is concerned, it has the highest priority in the 
network and will always act as the master. Grandmaster clocks are designed to be highly precise. Great accuracy is 
most imperative here since all clocks in the KGCS network will be synced to the signal created by this device. If the 
grandmaster clock has the wrong time, all of KGCS will have the wrong time. To help achieve this accuracy, 
Symmetricon designed this clock to obtain its time using the Global Positioning System (GPS) [4]. 

B. Juniper SRX240 Firewall 

Due to the large scale of KSC’s timing network, it has become useful for KGCS to isolate its own timing 
network. Therefore, a firewall was put in place between the grandmaster clock and the KGCS network. Once 
configured properly, the firewall will ensure that only PTP or NTP timing signals are permitted to pass through the 
firewall. This increases local security, guarding the KGCS network in case the security of T&CD is compromised. 
Juniper’s SRX240 firewall can be configured to set specific ports on the firewall to be trusted or untrusted. Setting 
configuration rules allows the user to control what type of information that enters an untrusted port is allowed to 
leave the firewall through the trusted ports. In this case, the grandmaster clock was connected to an untrusted port 
and the boundary clock was connected to a trusted port. Much of the configuration for the firewall was completed 
by Shania Sanders in the fall of 2014 [5]. For the initial proof of concept, the firewall was configured to allow all 
data to pass through. 

C. Allen-Bradley Stratix 8000 Boundary Clock 

In a PTP network, a boundary clock is essentially a device that acts as both a master and a slave. The Stratix 
8000 Boundary Clock is an Allen-Bradley product that acts like a network switch"* with a robust internal clock. In 
this prototype, the Stratix would be used to distribute the timing signal from the firewall to the rest of the KGCS 
network. Unlike a simple Ethernet hub^, which would simply pass the PTP signal to anything else connected to it, a 
boundary clock syncs its own clock to the master, and acts as a master to any devices on the other side. This has 
several uses. If the connection to the grandmaster clock is lost for any reason, the boundary clock’s own internal 
clock will still function to provide time to the rest of the network. In addition, since the firewall is not “PTP- 
smart”®, devices within the network might have trouble syncing to the grandmaster clock through the firewall. 
Having a PTP-smart boundary clock assures that as long as the boundary clock can sync to the grandmaster clock, 
all other devices within the network will be able to sync correctly. 

D. Wireshark 

Another capability of the Stratix was that it allowed one of its ports to be set to port-mirroring. A port that is set 
to port-mirroring simply mirrors the traffic entering or leaving another port on the switeh. This allows a “port- 
sniffing” tool such as Wireshark to see this traffic. This is very useful for debugging an Ethernet network. Eor 
example, if a given packet is not being received by an end-item, Wireshark can be used to trace the packet to 
determine where the signal is being lost. 

E. PEC’s and Workstations 

To test that the PTP signal could sync end-items properly, several devices were used as PTP-slaves following the 
Stratix boundary clock. Allen-Bradley PECs were used, as well as a Windows Server 2008 machine and a Windows 
7 machine. These devices needed to be PTP-smart in order to correctly act as a slave and sync to a master. The 


^ Controlled by T&CD. 

"* A network switch connects devices in a computer network, receiving, processing, and forwarding data to the 
destination device. 

^ An Ethernet hub is a device for connecting Ethernet devices together and making them act as a single network 
segment. 

® i.e. the firewall does not act as a master/slave or follow the protocol for interacting with a PTP signal; it simply 
receives the signal and passes it on as it would any IP packet. 
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PLCs have built-in PTP capability, but the Windows machines require software to function in this way. Two types 
of software were tested to provide this functionality; the Domain Time II client^ and the Studio 5000 Clock Sync 
Tool®. 


IV. Issues with the Early Prototype 

PTP was designed to be a single-network solution, and the protocol recommends the avoidance of routing PTP 
signals^ to guarantee the high accuracy the protocol claims. For this reason, the default time-to-live (TTL) for PTP 
packets is set to 1 on most PTP devices. TTL defines the number of router “hops” a packet can go through before 
the packet is dropped. When a router obtains a packet and passes it on to another network, it decreases the TTL of 
the packet by 1 ; if the TTL reaches zero, the packet is dropped and does not travel further. 

This TTL issue was problematic for the KGCS timing prototype because of the existence of the firewall. 
Wireshark sniffing on the Stratix 8000 revealed that while PTP packets reached the boundary clock perfectly when 
the grandmaster clock was connected directly to the boundary clock, once the firewall was introduced the PTP 
packets disappeared. This was originally believed to be caused by an error in the firewall configuration. However, 
this would even occur when the firewall was configured to pass all packets. Upon careful inspection^®, it was 
discovered that the TTL of PTP packets from both the grandmaster clock and the boundary clock were set to 1 . Asa 
result, whenever these packets would attempt to pass through the firewall, the firewall would decrement the TTL to 
zero, causing the packet to be dropped. 

After communicating this issue to T&CD, they were able to increase the TTL of the grandmaster clock’s PTP 
signals to 5* **. These packets were then able to be seen reaching the boundary clock, even in the presence of the 
firewall. However, this was not enough, since the boundary clock also needs to send delay request messages back to 
the grandmaster clock. Unfortunately, Allen-Bradley does not allow the TTL of their products to be changed. Thus, 
the Stratix 8000 had to be replaced. 


V. Final Timing Prototype 
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Figure 2 - Final Timing Prototype 


^ Developed by Greyware 
® Developed by Allen-Bradley 

® i.e. sending PTP signals between different networks 
i.e. meticulous examination of Wireshark data 

** Setting the TTL to 2 would have been sufficient, but 5 was selected in case more routing is required in the future. 
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The final timing synchronization prototype is shown above. The Stratix 8000 was replaced by a Windows 
Server 2008 machine with two network interface cards (NICs) - one for receiving the timing signal from the 
firewall, and another for sending a timing signal to the KGCS network. Due to differing limitations on the Domain 
Time II client software and the Clock Sync Tool software, the final solution used both products, each assigned to 
one of the NICs. 

The Domain Time II Client does not support functionality as a boundary clock, or even as a FTP master. 
Therefore, it could not be used to send a PTP signal from the server to the KGCS network. However, it functions 
very well as PTP slave software, easily allowing the user to set the TTL of outgoing multicast packets like PTP. 
Using this software and increasing the TTL quickly allowed the server to sync to the grandmaster, even in the 
presence of the firewall. 

The Clock Sync Tool had the opposite restraint. Being an Allen-Bradley product, it would not allow the user to 
change the TTL of the packets. This prohibited it from being used to obtain the PTP signal from the grandmaster 
clock in the presence of the firewall. On the other hand, this software can be configured to act as a master as well as 
a slave. Thus, it will be used to send timing signals from the server to the KGCS network. Note: The Clock Sync 
Tool only runs correctly on 64-bit Windows. 32-bit Windows cannot be used for this configuration. 

Since the server used only had two Ethernet ports, an Industrial Control Managed Ethernet Switch was placed 
between the server and the rest of the KGCS network. This switch is not a router, and can pass PTP packets without 
fear of the TTL being decreased. 


VI. Accomplishments 

The work involved for this internship consisted of debugging the early prototype to discern the cause of error, 
assisting the development of the final network solution, and testing the final prototype. I monitored the network 
using Wireshark and communicated with Juniper until it was discovered that the reason the PTP packets were not 
making it through the firewall was because they had a TTL of 1 . I then analyzed the Domain Time II and Clock 
Sync Tool software products to determine which could allow a TTL greater than 1 and found the capabilities and 
limitations of each. Once it was clear that each software had a clear purpose in the prototype, I helped design the 
final network solution that used two NICs and both software solutions. I tested the capability of this final prototype 
and verified its validity by successfully syncing the server to the grandmaster clock through the firewall. 

VII. Conclusion 

The goal of this internship, to pass a PTP signal from a grandmaster clock through a firewall to the KGCS 
network, was a success. The next task will be to further configure the firewall. More strict rules must be added so 
that the firewall only allows PTP and NTP timing signals through. In addition, although PTP is now working. 
Greyware*^ highly recommends the implementation of a backup NTP source in case the server fails to sync to the 
PTP signal from the grandmaster clock. 
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